In a traditional data network, the functions relating forwarding traffic and determining where to send traffic is done by a single apparatus. For example, an Ethernet switch in a data network is commonly said to contain a control plane and a data plane. The data plane sometimes referred to as a forwarding plane or a media plane. Data networks are sometimes referred to as computer networks, computing networks, or simply networks. These terms are used interchangeably in this specification.
For an Ethernet switch in a traditional data network for example, a control plane typically determines how an Ethernet frame is to be forwarded (e.g., the next hop for the frame and the outgoing port for the frame), and the data plane is in charge of forwarding the frame. The control plane typically includes one or more forwarding/routing protocols (e.g., Border Gateway Protocol (BGP), Interior Gateway Protocol(s) (IGP) (e.g., Open Shortest Path First (OSPF), Spanning Tree Protocol (STP), Intermediate System to Intermediate System (IS-IS), Label Distribution Protocol (LDP), Internet Control Message Protocol (ICMP)) that communicate with other network devices to exchange paths and select those paths based on one or more metrics. The data plane forwards frames based on input from the control plane.
The traditional integrated approach of the control plane and the data plane being tightly coupled in a single box may result in an overly complicated control plane and complex network management. Due to high complexity, equipment vendors and network operators are often reluctant to initiate changes and the network itself can become fragile and hard to manage over time. This is known to create a large burden and high barrier to new protocol and technology developments.
Software Defined Networking (SDN) is a network architecture that aims at decoupling control plane functions from data plane functions such that separate apparatuses may be utilized for different functions. In the SDN architecture, network intelligence and states are logically centralized, and the underlying network infrastructure is abstracted from the applications. As a result, networking may be simplified and new applications become feasible. For example, network virtualization can be accomplished by implementing it in a software application where the control plane is separated from the data plane. Also, a network administrator of a SDN system may have programmable central control of network traffic without requiring physical access to the system's hardware devices. With these benefits, SDN architecture based systems (referred to as SDN systems or SDN networks exchangeably herein below) are gaining popularity among carriers and enterprises.
One approach to popularize SDN architecture is to apply globally aware and topology decoupled software control at the edges of a core network. The assumption is that traditional topology-coupled network devices drive core networks (often an IP based networks), and SDN architecture should keep scalability, interoperability, high-availability, and extensibility of the core network intact. Thus a set of open commands for forwarding traffic has been defined in the form of a protocol known as OpenFlow (OF). The OpenFlow protocol enables globally aware centralized or distributed software controllers to drive the network edge hardware in order to create an easily programmable identity based overlay on top of the traditional core networks. The OpenFlow protocol has been standardized by specifications. For example, the Open Networking Foundation (ONF), an industrial consortium focusing on commercializing SDN and its underlying technologies, has been promoting OpenFlow specifications (latest version being 1.3.2, approved in September 2012).
In a SDN network, flow tables are used to direct traffic routing, where a field of a flow table matching with a field of an incoming traffic directs an incoming traffic to take instructions within the flow table. In early SDN architectures, a large flat table has been proposed to forward traffic. Yet a single table for traffic forwarding comes with complex rules associated with the single table. Thus, later SDN architectures (e.g., one complying with OpenFlow specification version 1.1.0) utilize multiple tables for traffic processing in a SDN network. When multiple tables are utilized, how to optimize multiple flow table lookup is a challenge.